Hi Gianluca,

Thanks for working on this! I'll comment on features now.

Media files

Currently, it is possible to use a custom template with nulled api_js block, e.g.:

# my_map.html
{% extends "easy_maps/map.html" %}
{% block api_js %}{% endblock %}

# user template
<script type="text/javascript" src="https://maps.google.com/maps/api/js?sensor=false"></script>

{% easy_map ... using "my_map.html" %}
{% easy_map ... using "my_map.html" %}

This doesn't require using custom widget for a form field, and this also doesn't require using a form.
1f0a767 brokes backwards-compatibility by requiring user to include <script> tag manually or using a form with AddressWithMapWidget.

I don't want django-easy-maps to be tied to forms, and I really like that it is possible to just drop {% easy_map "<My address>" 300 300 %} and get a map (e.g. at a "Contacts" page).

Currently, the inlined javascript may become an issue if multiple instances of the same map are displayed (because the template is parametrized by map.pk), but this is rarely an issue (and this limitation still apply in your branch).

But using Media in admin widget is a good idea. Maybe use an another template while rendering widgets, the one which assumes the external javascript is loaded? It is also better to put easy_maps javascript files to static/easy_maps/js or static/easy_maps, not to static/js because the latter may clash with user files.

Settings

+1 for defaults in settings, this may be useful.

Interactivity

This is a really useful feature, but I think it is better to move work to the client side. Shouldn't we use javascript geocoder instead of geopy/json api in this case ( see https://developers.google.com/maps/documentation/geocoding/#ReverseGeocoding )? I'd prefer the interactivity to be implemented purely in javascript.

Inlines

+1

Multiple markers

I like the idea. Currently easy_maps tag accepts either string or Address instance; is it possible to have multiple markers with just strings or form fields? What should syntax look like?

Change list

I like the idea.

By the way, https://github.com/gipi/django-easy-maps/blob/list-addresses/easy_maps_tests/test_app/models.py is not how django-easy-maps was intended to be used :) The idea was to write

class Shop(models.Model):
    address = models.CharField(max_length=255)
    brand = models.ForeignKey(Brand)

(that's what existing sites probably have) and then use {% easy_map shop.address 300 300 %} tag to render the map for shop's address; Address model is more like a geocoder cache with some fine-tuning options.

Thanks for your reply.

Address model is more like a geocoder cache with some fine-tuning options.

this explains a lot to me and I can say that my intention was to improve the admin-side of this application :)

Media Files

IHMO is better to avoid to include the Google's script in the widget and to tell the user to include it in the main template, otherwise we could add an optional version of the tag like

{% easy_map address 300 300 with_js=False %}

(using a custom template for a common case is annoying).

1f0a767 brokes backwards-compatibility by requiring user to include script tag manually or using a form with AddressWithMapWidget.

could be milestoned for a next major version a change in that, maybe indicating it in the documentation, obviously if you are ok with this.

Currently, the inlined javascript may become an issue if multiple instances of the same map are displayed (because the template is parametrized by map.pk), but this is rarely an issue (and this limitation still apply in your branch).

I don't understand what you mean, could you make an example?

It is also better to put easy_maps javascript files to static/easy_maps/js or static/easy_maps, not to static/js because the latter may clash with user files.

ok, I'll commit this

Interactivity

If we move the geocoding code client side (hence removing geo.py) can be problematic in browsers without javascript enabled.

Multiple markers

I like the idea. Currently easy_maps tag accepts either string or Address instance; is it possible to have multiple markers with just strings or form fields? What should syntax look like?

{% easy_map "address1" "address2" 300 300 %}

I don't understand the form fields stuffs, could you elaborate that?

BTW since there are some things you are ok with, you could indicate me what commits keep (or modify) so that I can reorganize this branch with only them in it in order to allow you to merge and maybe you could open an issue for each argument in this discussion with the guideline of implementations.

Hi @gipi and sorry for a long delay!

Media files

I like the idea of "with_js" attribute. However there are 3 possibilities:

a) include all the js (script tag with a link to Google and our js map initialization code);
b) include only our map init code;
c) include nothing.

"with_js" should do (b) - but then it needs a better name because some js would still be included :) Any ideas?

I think we shouldn't change the default (with_js=True) though.

Currently, the inlined javascript may become an issue if multiple instances of the same map are displayed (because the template is parametrized by map.pk), but this is rarely an issue (and this limitation still apply in your branch).
I don't understand what you mean, could you make an example?

I mean passing the same Address instance to several easy_maps tags on the same page. They would have the same pk and js code may become incorrect. I don't know if this is a real-life issue.

Interactivity

Interactivity wouldn't work without js anyway, would it? Client-side requests make more sense because they provide the same capabilities and don't block the server. I think we should do geocoding (user enters the address) both on server side (when interactivity is not available or the address is hard-coded in template) and on client side (when interactivity is enabled), and we should do reverse geocoding (when user clicks the map) only on client side; the UI is a tricky part for geocoding. I think the implementation may include some hidden fields.

Multiple markers

I mean "model fields" :) The syntax for static addresses looks good for me. But what with querysets? For example, we have some Shops in database; each shop has an "address" TextField. How to create a map with their addresses on the same map?

I think that settings for the default map center are ready (btw, I like EASY_MAPS_CENTER = (45.0677201, 7.6825531) more, but feel free to EASY_MAPS_CENTER_LAT if you want); other things need some work. It'll be great if you split the features so that we can discuss them faster.

ok, I'll create a branch of each feature; I think for the end of the week maybe :)